feat(releasing): add deprecation.d fragment system#25442
Conversation
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
2 similar comments
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
4 similar comments
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
d2b0864 to
0bc71cc
Compare
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0bc71ccdd4
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
The deprecations index lived at /releases/deprecations/ because the content file was under content/en/releases/. That coupled the URL to the releases section even though the page is its own concept (an always-current catalog of active and past deprecations, not a release artifact). Move: content/en/releases/deprecations.md -> content/en/deprecations.md layouts/releases/deprecations.html -> layouts/_default/deprecations.html New URL: /deprecations/. Updated the intra-link in the per-release deprecations partial to point at the new path.
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
…t flow The "Deprecation" and "Removal" sections still promised that we notify users via the release upgrade guide, but the rewritten Process section treats the deprecation.d fragment (rendered on the release page and the deprecations index) as the canonical user-facing notification. Update both lifecycle sections to match: the fragment / enacted entry is the default; the upgrade guide remains an option for richer treatment when warranted, not a per-deprecation requirement.
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
Apply Thomas's suggestion: the component-docs step now mentions both
the cue file path (`deprecation: "..."`) and the macro path
(`#[configurable(deprecated = "use <alternative> instead")]`), and
notes that the step is conditional ("if applicable") since not every
deprecation touches a documented config field.
Enacting a deprecation is part of the PR that removes the deprecated feature, not part of release preparation. By the time the release template kicks in, all enacts should already be on master. Keep the `vdev deprecation show` review checkpoint; drop the `enact` step.
Sharpens the changelog-fragment story: - Announcing a deprecation is communication, not a code change. The feature still works. The deprecation.d/ fragment itself is the announcement; doubling it as a changelog.d/ entry is redundant. Drops the "Add a deprecation changelog fragment" line from the introducing-a-deprecation step. - Enacting (removing) a deprecation IS the breaking change. The feature stops working. That belongs in changelog.d/*.breaking.md alongside other breaking changes. The Past Deprecations section is the lifecycle view for a different reader, not a replacement. Net effect: the two lifecycle stages get the artifacts they actually warrant, with no double-write at either end.
…nges Closes a gap: nothing in the policy required a breaking change to have a prior deprecation announcement, so a PR could ship a removal without warning. Now reviewers should ask for the announcement first, then come back for the removal once the migration window has passed. Restates the existing security/critical-bug exception so it has to be called out deliberately, not by accident.
Per review: - Require `description` (currently optional in the schema; all data has it anyway). - DRY the enacted entry by embedding #DeprecationEntry instead of restating its fields, then adding `removed_in`. Using `&` (or `|`) doesn't work here because #DeprecationEntry is a closed definition; embedding produces the intended four-field shape.
Each release-page deprecation section should exist only for information that isn't already in the changelog. Enactments are recorded as a type="breaking" changelog fragment, so they appear in the per-release Vector Changelog → Breaking changes section. Duplicating them as an "Enacted Deprecations" block on the same page was visible double-write without an additional reader benefit. Announcements are different: they have no changelog fragment (an announcement is not a change), so they only have one release-bound surface and that surface needs to stay. The lifecycle view (active + past deprecations) is preserved on /deprecations/. Only the per-release page is affected here.
|
Your preview site for the vector.dev will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the Rust Doc will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
|
Your preview site for the VRL Playground will be ready in a few minutes, please allow time for it to build. Heres your preview link: |
Summary
Introduces a
deprecation.d/fragment system that tracks deprecations as structured markdown files with YAML frontmatter, replacing the hand-maintaineddocs/DEPRECATIONS.mdtable.Each fragment carries:
what— short description of what's deprecateddeprecated_since— concrete semver (e.g.0.56.0)description— free-form Markdown migration guidanceNew
vdevcommandscargo vdev deprecation show [--version X.Y.Z]— list fragments grouped into announced / planned / enacted buckets for a target releasecargo vdev deprecation enact <slug> [--version X.Y.Z]— record an enacted entry in the generated JSON and remove the fragmentcargo vdev deprecation generate— regeneratewebsite/cue/reference/generated/deprecations.jsonfrom fragmentscargo vdev check deprecations— validate fragments and ensure the generated JSON is up to dateCI
A new GitHub Actions workflow (
.github/workflows/deprecation.yaml) runsvdev check deprecationswhendeprecation.d/or the generated JSON change.Website
CUE schema additions (
#DeprecationEntry,#EnactedDeprecationEntry) and Hugo templates render deprecations on:/releases/deprecationsindex page{{< deprecations >}}shortcode for ad-hoc inclusionThe website build pipeline runs
vdev deprecation generatebeforecue-build.Migration
docs/DEPRECATIONS.mdmigrated to fragment filesdocs/DEPRECATIONS.mddeleteddocs/DEPRECATION.mdrenamed todocs/DEPRECATION_POLICY.md(links updated inCONTRIBUTING.md,docs/REVIEWING.md)vdev deprecation show/enactstepsVector configuration
NA
How did you test this PR?
cargo test -p vdev— 59 tests passcargo clippy -p vdev— cleancargo vdev check deprecations— validates all 5 migrated fragments and confirms generated JSON is up to datecargo vdev deprecation show— verified bucket outputChange Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References